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DETAILED ACTION 

1. A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 
December 29, 2008 has been entered. 

2. Applicant's amendment dated December 29, 2008, responding to the Office 
action mailed June 25, 2008 provided in the rejection of claims 1, 3-28, and 30-45, 
wherein claims 1, 7, 15, 20, 23, 28, 32, and 34 have been amended, claims 37, 39, 41, 
43 and 45 are being canceled. 

Claims 1, 3-28, 30-36, 38, 40, 42, and 44 remain pending in the application and 
which have been fully considered by the examiner. 

Applicant's arguments with respect to claims currently amended have been fully 
considered but are moot in view of the new grounds of rejection - see APA (Applicant's 
Admitted Prior Art) as applied hereto. 

Claim Objections 

3. Claims 2, 7, 9, 30 and 31 are objected to because the following informalities: 



Application/Control Number: 10/681,057 Page 3 

Art Unit: 2192 

• "The method of claim 2 claim 2, line 1 , should be corrected "The method 
of claim 1 ..." 

• "The method of claim 2 claim 7, line 1 , should be corrected "The method 
of claim 1 ..." 

• "The method of claim 2 claim 9, line 1 , should be corrected "The method 
of claim 1 ..." 

• "The system of claim 29 . . .", claim 30, line 1 , should be corrected "The 
message processing architecture of claim 28 ..." 

• "The system of claim 29 . . .", claim 31 , line 1 , should be corrected "The 
message processing architecture of claim 28 ..." 

Appropriate correction is required (See MPEP § 608.01(b)) 

Claim Rejections - 35 USC § 101 
35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

4. Claims 28 and 30-31 are rejected under 35 U.S.C 101 because the claims are 
directed to non-statutory subject matter. 

5. As to claim 28, "A message processing architecture comprising ... an 
development module ... an program compiler ... a message parser ..." is being cited 
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(underline emphasis added); however, it appears that the development module, the 
program compiler, and the message parser (cited on paragraph [0014] in the 
specification) would reasonably be interpreted by one of ordinary skill in the art as 
computer listings per se, are not physical "things". They are neither computer 
components nor statutory processes, as they are not "act" being performed. Such 
claimed computer programs do not define any structural and functional 
interrelationships between the computer program and other claimed elements of a 
computer which permit the computer program's functionality to be realized. 

In contrast, a claimed computer readable medium encoded with a computer 
program is a computer element which defines structural and functional interrelationships 
between the computer program and the rest of the computer which permit the computer 
program's functionality to be realized, and is thus statutory. Accordingly, it is important 
to distinguish claims that define descriptive material per se from claims that define 
statutory inventions. (See MPEP 2106.01(1)) 

6. As to claims 30-31 , they do not cure the deficiency of base claim 28, and also 
are rejected under 35 U.S.C. 101 as set forth above. 

Claim Rejections - 35 USC § 103(a) 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 1 02 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
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having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

7. Claims 1, 3-28, 30-36, 38, 40, 42, and 44 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Samo Zorc (Pub. No. US 2003/0167444 A1) (hereinafter 
'Zorc') in view of Michael Koch (Leverage legacy systems with a blend of XML, XSL, 
and Java®, October 6, 2000, JavaWorld.com - appeared on JavaWorld at 
<http://www.javaworld.com/javaworld/jw-10-2000/jw-1006-legacy.html>) (hereinafter 
'Koch') and Applicant's admitted prior art (paragraph [0005] on page 3 is clearly 
admitted "to transfer a payload message directly between the program language and 
the OLTP language" disclosed in the instant application - hereinafter 'APA') 

8. As to claim 1 (Currently Amended), Zorc discloses a method of processing 
messages comprising: 

• receiving a markup language document describing a message (e.g., Fig. 2, 
XML Message Definition; [0009] - ... directly from an XML schema message 
definition ); 

• automatically generating source code in the program language from the 
markup language document and the template (e.g., [0010] - ... automatically 
generating source code based on a mark-up language message definition ...; 
NOTE: Koch reference teaches using both XML (Extensible Markup 
Language) and XSL (Extensible Stylesheet Language) to generate a 
message, please see further statements below); and 



Application/Control Number: 10/681,057 Page 6 

Art Unit: 2192 

• compiling the source code (e.g., [0009] - ... a mechanism is provided for 
automatically generating a conversion module directly from an XML schema 
message definition : [0010]; [0026] - ... a compilation mechanism for 
automatically generating the conversion module ...) 
Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023] - [0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the markup language document being compliant with message rules associated 
with an OLTP language (e.g., P. 5, Sec. of "Conclusion" - XML , XSL, and Java ® 
work hand in hand to solve the complex problem of mainframe transaction 
access . . . XML allows us to describe the structure of the COBOL transaction 
(compliant with message rules associated with an OLTP language), providing 
directions to the Java® engine on how to build the request or parse the response 

...); 

• receiving a template for a data format for the message in a program language 
(e.g., P. 2, Sec. of " XSL Style ", 1 st Para - ... use the XSL language for 
manipulating XML from one structure into another ) 
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Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating the Koch's system which offers significant advantages 
that XML allows us to describe the structure of the COBOL transaction, providing 
directions to the Java® engine on how to build the request or parse the response as 
once suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses that XML describes the structure of the data you 
are sending; add XSL to complete some simple transformations (e.g., P. 1, 2 nd Para) but 
Zorc and Koch do not explicitly disclose other limitations stated below. 

However, APA discloses using the compiled source code to transform a payload 
message directly between the program language and the online transaction processing 
(OLTP) language (e.g., [0005] - ... a message parser receives a message in either the 
program language or the OLTP language and uses the compiled source code to 
transform the message between the program language and the OLTP language ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 

The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 
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9. As to claim 3 (Original) (incorporating the rejection in claim 2), Koch discloses 
the method wherein the message rules define markup tags for describing components 
of the message (e.g., Sec. of "The versatile XML, 3 rd Para - Using XML, you can now 
implement that copybook metadata to generate your copybook markup language; 
Below, this short, simplistic example of an XML document containing our COBOL 
program's metadata retrieves a name when given a social security number) 

10. As to claim 4 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the message is a request message from an application to an OLTP 
host (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing message 
structure", "incoming message structure") 

11. As to claim 5 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the message is a response message from an OLTP host to an 
application (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing 
message structure", "incoming message structure") 

12. As to claim 6 (Original) (incorporating the rejection in claim 3), Koch discloses 
the method wherein the markup language is an extensible markup language (e.g., Sec. 
of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - XML 
describes the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will then 
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leverage a host of legacy system transactions written decades ago and development 
becomes easier; In addition, the solution, you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch interface) 

13. As to claim 7 (Currently Amended) (incorporating the rejection in claim 2), Koch 
discloses the method wherein the template comprises the stylesheet data for the 
message in the program language (e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use XSL 
to format an incoming document structure to the name/value-pair structure . . . which the 
Java® code processes into the COBOL structure . XSL will also format the data returned 
from the legacy system ... Java code transforms it back into XML ...) 

14. As to claim 8 (Original) (incorporating the rejection in claim 7), Koch discloses 
the method further including using a stylesheet parser to compile the markup language 
document (e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use XSL to format an incoming 
document structure to the name/value-pair structure . . . which the Java® code 
processes into the COBOL structure . XSL will also format the data returned from the 
legacy system ... Java code transforms it back into XML ...) 

15. As to claim 9 (Original) (incorporating the rejection in claim 2), Zorc discloses 
the method further including receiving and compiling a plurality of markup language 
documents for a plurality of message types (e.g., [0009] - ... a mechanism is provided 
for automatically generating a conversion module directly from an XML schema 
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message definition : [0010]; [0026] - ... a compilation mechanism for automatically 
generating the conversion module ...) 

16. As to claim 10 (Original) (incorporating the rejection in claim 1), Zorc discloses 
the method wherein the program language is an object-oriented program language 
(e.g., [0023] - ... for generating or receiving object-oriented code (e.g., Java® objects)) 

17. As to claim 11 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method further including: 

• receiving one or more name-value pairs for the message according to the 
object- oriented program language (e.g., P. 5, 1 st bullet - since XSL is applied 
to the incoming document as well as the outgoing document, the Java engine, 
once written, is insulated from changes in the incoming message structure; 
the entire DTD, or schema, of the incoming message could be changed 
completely; a programmer would only have to modify the XSL within this 
framework that styles the document into your name/value-pair format; 1 st Para 
[after program listing] - essentially, the code matches the fields with value 
from the array and creates name/value pairs that are suitable for simplistic 
XML document); 

• generating a byte array according to the OLTP language; and transmitting the 
byte array to an application (e.g., 1 st Para [after program listing] - data 
manipulation transforms the response from a byte array or similar structure 
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into an XML document; essentially, the code matches the fields with value 
from the array and creates name/value pairs that are suitable for simplistic 
XML document). 

18. As to claim 12 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method further including: receiving a byte array for the message according to the 
OLTP language; generating one or more name-value pairs according to the object- 
oriented program language; and transmitting the name-value pairs to an application 
(e.g., P. 5, 1 st bullet - since XSL is applied to the incoming document as well as the 
outgoing document, the Java engine, once written, is insulated from changes in the 
incoming message structure; the entire DTD, or schema, of the incoming message 
could be changed completely; a programmer would only have to modify the XSL within 
this framework that styles the document into your name/value-pair format; 1 st Para [after 
program listing] - essentially, the code matches the fields with value from the array and 
creates name/value pairs that are suitable for simplistic XML document) 

19. As to claim 13 (Original) (incorporating the rejection in claim 10), Koch discloses 
the method wherein the object-oriented program language is a Java language (e.g., 
Sec. of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - 
XML describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
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development becomes easier; In addition, the solution, you employ is realtime, which 
circumvents the frustrations and problems that arise from working with an extract file or 
batch interface) 

20. As to claim 14 (Original) (incorporating the rejection in claim 1 ), APA discloses 
the method wherein the OLTP language is a gaming system language (e.g., [0003] 
The OLTP host is responsible for managing the particular game being played ...) 

21 . As to claim 15 (Currently Amended), Zorc discloses a method of generating 
source code comprising: 

• receiving a markup language document (e.g., Fig. 2, XML Message Definition; 
[0009] directly from an XML schema message definition ); and 

• automatically generating a source code based on the markup language 
document and the template (e.g., [0010] - ... automatically generating source 
code based on a mark-up language message definition ...) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 
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However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• receiving a template for a data format in a program language for a message 
(e.g., P. 2, Sec. of " XSL Style ", 1 st Para - ... use the XSL language for 
manipulating XML from one structure into another ): and 

• the markup language document being compliant with message rules associated 
with an online transaction processing (OLTP) language (e.g., P. 5, Sec. of 
"Conclusion" - XML , XSL, and Java ® work hand in hand to solve the complex 
problem of mainframe transaction access . . . XML allows us to describe the 
structure of the COBOL transaction (compliant with message rules associated 
with an OLTP language), providing directions to the Java® engine on how to 
build the request or parse the response ...) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract), but does not 
explicitly disclose other limitations stated below in the Zorc system. 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
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to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses that XML describes the structure of the data you 
are sending; add XSL to complete some simple transformations (e.g., P. 1, 2 nd Para) but 
Zorc and Koch do not explicitly disclose other limitations stated below. 

However, APA discloses the source code enabling transformation of a payload 
message directly between a program language and the OLTP language (e.g., [0005] - 
. . . a message parser receives a message in either the program language or the OLTP 
language and uses the compiled source code to transform the message between the 
program language and the OLTP language ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 

The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

22. As to claim 16 (Original) (incorporating the rejection in claim 15), Koch discloses 
the method wherein the message rules define markup tags for describing components 
of the message (e.g., Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2 nd Para - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to encapsulate 
it with a few simple classes; You will then leverage a host of legacy system transactions 
written decades ago and development becomes easier; In addition, the solution, you 
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employ is realtime, which circumvents the frustrations and problems that arise from 
working with an extract file or batch interface; Fig. 1 - Legacy transaction framework, 
elements of "Calling Application", "Java Engine", "Outgoing message structure", 
"Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - XML, XSL, 
and Java work hand i hand to solve the complex problem of mainframe transaction 
access; Implementing XSL styling creates supplementary layers in the framework that 
allow the solution to configure changes from the application server or the mainframe 
programs without recompiling the Java code that performs the mapping; XML allows us 
to describe the structure of the COBOL transactions, providing directions to the Java® 
engine on how to build the request or parse the response) 

23. As to claim 17 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the message is a request message from an application to an OLTP 
host (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing message 
structure", "incoming message structure"). 

24. As to claim 18 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the message is a response message from an OLTP host to an 
application (e.g., Fig. 1 - Legacy transaction framework, elements of "outgoing 
message structure", "incoming message structure") 
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25. As to claim 19 (Original) (incorporating the rejection in claim 16), Koch discloses 
the method wherein the markup language is an extensible markup language (e.g., Sec. 
of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - XML 
describes the structure of the data you are sending; Add XSL to complete some simple 
transformations; Use Java® to encapsulate it with a few simple classes; You will then 
leverage a host of legacy system transactions written decades ago and development 
becomes easier; In addition, the solution, you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch interface) 

26. As to claim 20 (Currently Amended) (incorporating the rejection in claim 15), 
Koch discloses the method wherein the template comprises stylesheet data for the 
message in the program language (e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use XSL 
to format an incoming document structure to the name/value-pair structure . . . which the 
Java® code processes into the COBOL structure . XSL will also format the data returned 
from the legacy system ... Java code transforms it back into XML ...) 

27. As to claim 21 (Original) (incorporating the rejection in claim 20), Koch discloses 
the method further including using a stylesheet parser to compile the markup language 
document (e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use XSL to format an incoming 
document structure to the name/value-pair structure . . . which the Java® code 
processes into the COBOL structure . XSL will also format the data returned from the 
legacy system ... Java code transforms it back into XML ...) 
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28. As to claim 22 (Original) (incorporating the rejection in claim 15), Zorc discloses 
the method further including receiving and compiling a plurality of markup language 
documents for a plurality of message types (e.g., [0009] - ... a mechanism is provided 
for automatically generating a conversion module directly from an XML schema 
message definition : [0010]; [0026] - ... a compilation mechanism for automatically 
generating the conversion module ...) 

29. As to claim 23 (Currently Amended), Zorc discloses a method of processing 
messages comprising: 

• receiving one or more extensible markup language (XML) documents (e.g., Fig. 
2, XML Message Definition; [0009] - ... directly from an XML schema message 
definition ); 

• compiling the XML documents into source code in an object-oriented program 
language based on stylesheet data (e.g., [0010] - ... automatically generating 
source code based on a mark-up language message definition ...); 

• compiling the source code (e.g., [0009] - ... a mechanism is provided for 
automatically generating a conversion module directly from an XML schema 
message definition ; [0010]; [0026] - ... a compilation mechanism for 
automatically generating the conversion module ...); 

• the source code being generated automatically (e.g., [0010] - ... automatically 
generating source code based on a mark-up language message definition ...); 
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• repeating the receiving and compiling of XML documents and the compiling of 
source code for a plurality of message types (e.g., Fig. 3, element 314 - 
Message Definition) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• the XML documents being compliant with message rules associated with an 
online transaction processing (OLTP) language and the message rules defining 
markup tags for describing components of the message (e.g., P. 5, Sec. of 
"Conclusion" - XML , XSL, and Java ® work hand in hand to solve the complex 
problem of mainframe transaction access . . . XML allows us to describe the 
structure of the COBOL transaction (compliant with message rules associated 
with an OLTP language), providing directions to the Java® engine on how to 
build the request or parse the response ...); and 

• the stylesheet data representing a program template for a payload message in 
the program language (e.g., P. 2, Sec. of "XSL Style", 1 st Para - ... use the XSL 
language for manipulating XML from one structure into another) 
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Therefore, it would have been obvious to one of ordinary skill in the art, at the time 
the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses that XML describes the structure of the data you 
are sending; add XSL to complete some simple transformations (e.g., P. 1, 2 nd Para) but 
Zorc and Koch do not explicitly disclose other limitations stated below. 

However, APA discloses the source code enabling transformation of the payload 
message directly between the program language and the OLTP language; using the 
compiled source code to transform a message between the program language and the 
OLTP language (e.g., [0005] - ... a message parser receives a message in either the 
program language or the OLTP language and uses the compiled source code to 
transform the message between the program language and the OLTP language ...); 
and the OLTP language being a gaming system language (e.g., [0003] - ... The OLTP 
host is responsible for managing the particular game being played ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 
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The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

30. As to claim 24 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including using a stylesheet parser to compile the XML documents 
(e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use XSL to format an incoming document 
structure to the name/value-pair structure ... which the Java® code processes into the 
COBOL structure . XSL will also format the data returned from the legacy system ... 
Java code transforms it back into XML . . . ) 

31 . As to claim 25 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including: 

• receiving one or more name-value pairs for the message according to the 
program language (e.g., P. 5, 1 st bullet - since XSL is applied to the incoming 
document as well as the outgoing document, the Java engine, once written, is 
insulated from changes in the incoming message structure; the entire DTD, or 
schema, of the incoming message could be changed completely; a programmer 
would only have to modify the XSL within this framework that styles the 
document into your name/value-pair format; 1 st Para [after program listing] - 
essentially, the code matches the fields with value from the array and creates 
name/value pairs that are suitable for simplistic XML document); 
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• generating a byte array according to the OLTP language; and transmitting the 
byte array to an application (e.g., 1 st Para [after program listing] - data 
manipulation transforms the response from a byte array or similar structure into 
an XML document; essentially, the code matches the fields with value from the 
array and creates name/value pairs that are suitable for simplistic XML 
document) 



32. As to claim 26 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method further including: 

• receiving a byte array for the message according to the OLTP language (e.g., 
1 st Para [after program listing] - data manipulation transforms the response 
from a byte array or similar structure into an XML document; essentially, the 
code matches the fields with value from the array and creates name/value 
pairs that are suitable for simplistic XML document); 

• generating one or more name-value pairs according to the program language; 
and transmitting the name-value pairs to an application (e.g., P. 5, 1 st bullet - 
since XSL is applied to the incoming document as well as the outgoing 
document, the Java engine, once written, is insulated from changes in the 
incoming message structure; the entire DTD, or schema, of the incoming 
message could be changed completely; a programmer would only have to 
modify the XSL within this framework that styles the document into your 
name/value-pair format; 1 st Para [after program listing] - essentially, the code 
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matches the fields with value from the array and creates name/value pairs 
that are suitable for simplistic XML document) 

33. As to claim 27 (Original) (incorporating the rejection in claim 23), Koch discloses 
the method wherein the object-oriented program language is a Java language (e.g., 
Sec. of "Combine XML, XSL, and Java to interface with mainframe systems", 2 nd Para - 
XML describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; You will 
then leverage a host of legacy system transactions written decades ago and 
development becomes easier; In addition, the solution, you employ is realtime, which 
circumvents the frustrations and problems that arise from working with an extract file or 
batch interface) 

34. As to claim 28 (Currently Amended), Zorc discloses a message processing 
architecture comprising: 

• a development module, the development module to receive a markup language 
document (e.g., Fig. 2, XML Message Definition; [0009] - ... directly from an XML 
schema message definition ) and automatically generate a source code in a 
program language (e.g., [0010] - ... automatically generating source code based 
on a mark-up language message definition ...), the source code based on the 
markup language document ; and 
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• a program compiler, the program compiler to compile the source code (e.g., 
[0009] - ... a mechanism is provided for automatically generating a conversion 
module directly from an XML schema message definition : [0010]; [0026] - ... a 
compilation mechanism for automatically generating the conversion module ...); 

• configured to generate a source in the program language, the source code based 
on the markup language document and the template (e.g., [0010] - ... 
automatically generating source code based on a mark-up language message 
definition ...) 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• a template for a message data format in a program language (e.g., P. 2, Sec. of 
" XSL Style ", 1 st Para - ... use the XSL language for manipulating XML from one 
structure into another ): and 

• the markup language document to be compliant with message rules associated 
with the OLTP language (e.g., P. 5, Sec. of "Conclusion" - XML , XSL, and Java ® 
work hand in hand to solve the complex problem of mainframe transaction 
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access . . . XML allows us to describe the structure of the COBOL transaction 
(compliant with message rules associated with an OLTP language), providing 
directions to the Java® engine on how to build the request or parse the response 
■■■) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses that XML describes the structure of the data you 
are sending; add XSL to complete some simple transformations (e.g., P. 1, 2 nd Para) but 
Zorc and Koch do not explicitly disclose other limitations stated below. 

However, APA discloses the source code to enable transformation of the payload 
message directly between the program language and the OLTP language; and the 
message parser to transform a payload message between the program language and 
an online transaction processing (OLTP) language using the compiled source code 
(e.g., [0005] - ... a message parser receives a message in either the program language 
or the OLTP language and uses the compiled source code to transform the message 
between the program language and the OLTP language ...) 
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Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 

The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

35. As to claim 30 (Original) (incorporating the rejection in claim 29), Koch discloses 
the system wherein the message rules define markup tags for describing components of 
the message (e.g., Sec. of "Combine XML, XSL, and Java to interface with mainframe 
systems", 2 nd Para - XML describes the structure of the data you are sending; Add XSL 
to complete some simple transformations; Use Java® to encapsulate it with a few 
simple classes; You will then leverage a host of legacy system transactions written 
decades ago and development becomes easier; In addition, the solution, you employ is 
realtime, which circumvents the frustrations and problems that arise from working with 
an extract file or batch interface; Fig. 1 - Legacy transaction framework, elements of 
"Calling Application", "Java Engine", "Outgoing message structure", "Incoming message 
structure", and "Legacy System"; Sec. of "Conclusion" - XML, XSL, and Java work hand 
i hand to solve the complex problem of mainframe transaction access; Implementing 
XSL styling creates supplementary layers in the framework that allow the solution to 
configure changes from the application server or the mainframe programs without 
recompiling the Java code that performs the mapping; XML allows us to describe the 
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structure of the COBOL transactions, providing directions to the Java® engine on how 
to build the request or parse the response) 

36. As to claim 31 (Original) (incorporating the rejection in claim 29), Koch discloses 
the system wherein the development module further includes a stylesheet parser, the 
development module to use the stylesheet parser to compile the markup language 
document based on stylesheet data (e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use 
XSL to format an incoming document structure to the name/value-pair structure . . . 
which the Java® code processes into the COBOL structure . XSL will also format the 
data returned from the legacy system ... Java code transforms it back into XML ...) 

37. As to claim 32 (Original), Zorc discloses a machine readable medium 
comprising a set of stored instructions capable of being executed by a processor to: 

• receive a markup language document (e.g., Fig. 2, XML Message Definition; 
[0009] directly from an XML schema message definition ): and 

• automatically generate a source code based on the markup language document 
and the template (e.g., [0010] - ... automatically generating source code based 
on a mark-up language message definition ...); 

Further, Zorc discloses a method and system for automatically generating source 
code based on a mark-up language message definition (e.g., Abstract) and conversion 
modules that convert some kind of internal representation of the data to an external 
representation (e.g., a specified communication message in XML format) and vice versa 
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(e.g., [0023]-[0025]; [0098]), but does not explicitly disclose other limitations stated 
below. 

However, in an analogous art of Leverage Legacy Systems with a blend of XML, 
XSL, and Java, Koch discloses: 

• receive a template for a data format in a program language relating to a message 
(e.g., P. 2, Sec. of " XSL Style ", 1 st Para - ... use the XSL language for 
manipulating XML from one structure into another ): and 

• the markup language document to be compliant with message rules associated 
with an online transaction processing (OLTP) language (e.g., Sec. of "Combine 
XML, XSL, and Java to interface with mainframe systems", 2 nd Para - XML 
describes the structure of the data you are sending; Add XSL to complete some 
simple transformations; Use Java® to encapsulate it with a few simple classes; 
You will then leverage a host of legacy system transactions written decades ago 
and development becomes easier; In addition, the solution, you employ is 
realtime, which circumvents the frustrations and problems that arise from working 
with an extract file or batch interface; Fig. 1 - Legacy transaction framework, 
elements of "Calling Application", "Java Engine", "Outgoing message structure", 
"Incoming message structure", and "Legacy System"; Sec. of "Conclusion" - 
XML, XSL, and Java work hand in hand to solve the complex problem of 
mainframe transaction access; Implementing XSL styling creates supplementary 
layers in the framework that allow the solution to configure changes from the 
application server or the mainframe programs without recompiling the Java code 
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that performs the mapping; XML allows us to describe the structure of the 
COBOL transactions, providing directions to the Java® engine on how to build 
the request or parse the response) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of Koch into the Zorc's system to 
further provide other limitations stated above in the Zorc system. 

The motivation is that it would further enhance the Zorc's system by taking, 
advancing and/or incorporating Koch's system which offers significant advantages that 
XML allows us to describe the structure of the COBOL transaction, providing directions 
to the Java® engine on how to build the request or parse the response as once 
suggested by Koch (e.g., P. 5, Sec. of "Conclusion") 

Furthermore, Koch discloses that XML describes the structure of the data you 
are sending; add XSL to complete some simple transformations (e.g., P. 1, 2 nd Para) but 
Zorc and Koch do not explicitly disclose other limitations stated below. 

However, APA discloses the source code enabling transformation of a payload 
message directly between the program language and the OLTP language (e.g., [0005] 
- . . . a message parser receives a message in either the program language or the OLTP 
language and uses the compiled source code to transform the message between the 
program language and the OLTP language ...) 

Therefore, it would have been obvious to one of ordinary skill in the art, at the 
time the invention was made to combine the teachings of APA into the Zorc-Koch's 
system to further provide other limitations stated above in the Zorc-Koch system. 
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The motivation is that the messages can be exchanged directly between the 
program language and the OLTP language. 

38. As to claim 33 (Original) (incorporating the rejection in claim 32), Koch discloses 
the medium wherein the message rules define markup tags for describing components 
of the message (e.g., Sec. of "Combine XML, XSL, and Java to interface with 
mainframe systems", 2 nd Para - XML describes the structure of the data you are 
sending; Add XSL to complete some simple transformations; Use Java® to encapsulate 
it with a few simple classes; You will then leverage a host of legacy system transactions 
written decades ago and development becomes easier; In addition, the solution, you 
employ is realtime, which circumvents the frustrations and problems that arise from 
working with an extract file or batch interface) 

39. As to claim 34 (Currently Amended) (incorporating the rejection in claim 32), 
Koch discloses the medium wherein the template comprises stylesheet data for the 
message in the program language (e.g., P. 2, Sec. of "XSL Style", 2 nd Para - ... use XSL 
to format an incoming document structure to the name/value-pair structure . . . which the 
Java® code processes into the COBOL structure . XSL will also format the data returned 
from the legacy system ... Java code transforms it back into XML ...) 



40. As to claim 35 (Original) (incorporating the rejection in claim 32), Zorc discloses 
the medium wherein the instructions are further capable of being executed to receive 
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and compile a plurality of markup language documents for a plurality of message types 
(e.g., [0009] - ... a mechanism is provided for automatically generating a conversion 
module directly from an XML schema message definition : [0010]; [0026] - ... a 
compilation mechanism for automatically generating the conversion module ...) 

41 . As to claim 36 (Previously Presented) (incorporating the rejection in claim 1 ), 
APA discloses the method further comprising: 

• providing an online gaming system by an OTLP host which uses the OLTP 
language, wherein the online gaming system processes wagering-related 
transactions (e.g., [0003] - The OLTP host is responsible for managing the 
particular game being played ...); and 

• providing an application at a consumer location which uses the program 
language, wherein the application provides access to the wagering-related 
transactions for the consumer (e.g., [0005] - ... to transform the message 
between the program language and the OLTP language ...); 

• wherein the payload message is part of at least one of the wagering-related 
transactions and comprises at least one of: a request to place an online wager, 
or a response to the request to place the online wager (e.g., [0005] - ... 
LottoWagerRequest message ... WagerResponse message ...) 

42. As to claim 38 (Previously Presented) (incorporating the rejection in claim 15), 
refer to claim 36 above accordingly. 
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43. As to claim 40 (Previously Presented) (incorporating the rejection in claim 23), 
refer to claim 36 above accordingly. 

44. As to claim 42 (Previously Presented) (incorporating the rejection in claim 28), 
refer to claim 36 above accordingly. 

45. As to claim 43 (Previously Presented) (incorporating the rejection in claim 28), 
Koch discloses the method wherein the payload message is transformed directly 
between the program language and the OLTP language (e.g., Fig. 1 - Legacy 
transaction framework, elements of "calling application", "Java engine", "outgoing 
message structure", "incoming message structure", and "legacy system") 

46. As to claim 44 (Previously Presented) (incorporating the rejection in claim 32), 
refer to claim 36 above accordingly. 

Conclusion 

47. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ben C. Wang whose telephone number is 571-270- 
1240. The examiner can normally be reached on Monday - Friday, 8:00 a.m. - 5:00 
p.m., EST. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on 571-272-3695. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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Examiner, Art Unit 2192 
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